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Architectural styles and patterns play an important role in software engineering. One of the most 
known ones is the layered architecture style. However, this style is usually only stated informally, 
which may cause problems such as ambiguity, wrong conclusions, and difficulty when checking the 
conformance of a system to the style. We address these problems by providing a formal, denotational 
semantics of the layered architecture style. Mainly, we present a sufficiently abstract and rigorous 
description of layered architectures. Loosely speaking, a layered architecture consists of a hierarchy 
of layers, in which services communicate via ports. A layer is modeled as a relation between used and 
provided services, and layer composition is defined by means of relational composition. Furthermore, 
we provide a formal definition for the notions of syntactic and semantic dependency between the 
layers. We show that these dependencies are not comparable in general. Moreover, we identify 
sufficient conditions under which, in an intuitive sense which we make precise in our treatment, the 
semantic dependency implies, is implied by, or even coincides with the reflexive-transitive closure 
of the syntactic dependency. Our results provide a technology-independent characterization of the 
layered architecture style, which may be used by software architects to ensure that a system is indeed 
built according to that style. 


1 Introduction 

Lack of discipline is a substantial technical source of failures in a number of software product lines 
[7, 15] (while other sources as, e.g., bad management, also exist). A poor architecture can result in a 
disaster for the whole project [10], hence, “expanding formal relationships between architectural design 
decisions and quality attributes” [19] has been identified as a promising future direction to go for the 
field. We address the lack of discipline in architectural design [4] by providing a formal model for one 
of the most important architectural styles, namely, the layered architecture style, which is also known as 
the virtual machines style. 

While this work contributes to a rigorous theory of architecture styles, we believe that it has also im¬ 
plications for the practicing architecture researcher and the prospective software architect. The software 
architecture researcher can rely on a mathematical model when working with styles, while the prospec¬ 
tive architect is provided with a solid foundation for her/his work. A theory of styles would provide 
the architect with a set of properties which allows her/him to decide whether a system is actually built 
according to a specific style, in our case, the layered architecture style. Moreover, the outcome of the 
analysis would provide the architect with a set of properties she/he can rely on from a system built ac¬ 
cording to a style, for example, semantic independence of lower-level layers from upper-level layers for 
systems built according to the layered architecture style. 


1.1 Approach 

In previous work [17], we describe an approach to formalize architectural styles. Based on the insight 
that each style requires its own semantic domain [1], this approach roughly follows three main steps: 
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• Find a mathematical model which reflects the nature of the style. This is probably the most difficult 
part, since the model must reflect the fundamental characteristics of a style. It should be as abstract 
as possible to allow the results of later analyses to be applied to a broad range of systems. If for 
some style an adequate model already exists, this step can be skipped. 

• Provide a set of axioms for the model which constrain its structure. Through the addition of 
new axioms it is possible to specialize a style and investigate variations thereof. For example, in 
the layered architecture style, a configuration is usually isomorphic to a directed acyclic graph. 
However, we could add an axiom which restricts configuration to a directed sequence of layers to 
get a description of the strict version of the style. 

• Finally, we can analyze a style by means of mathematical proofs. We can state characteristic 
properties for a style and prove them from our model. 

In the following we apply our approach to the layered architecture style as described in [9, 20, 22], 

Our major contributions arc: 

• an abstract and nonetheless precise notion of a layer (for this moment, one can loosely think of a 
layer as a provider of services that uses some other services), 

• a notion of a layered architecture configuration, which is a collection of layers connected via ports 
(detailed later in the paper), 

• a denotational semantics of a layered architecture configuration, 

• a model for updating a layer, i.e., changing its semantics, 

• for a pair of layers of a layered architecture configuration, the notions of 

- a syntactic dependency and 

- a semantic dependency, 

• examples on which the dependencies differ, 

• the following (for now intuitively stated) link between the dependencies: 

- in any layered architecture configuration the semantic dependency implies the reflexive- 
transitive closure of the syntactic dependency, 

- in any so-called usable layered architecture configuration the semantic dependency is equiv¬ 
alent to the reflexive-transitive closure of the syntactic dependency. 


2 Background and Related Work 

Related work can roughly be categorized in three main areas: approaches to formalization of archi¬ 
tectural styles, informal descriptions of the layered architecture style, and existing formal analyzes of 
architectural styles. 

In analyzing architectural styles, our work is actually based on work regarding approaches to for¬ 
malization of architectural styles. In our work, we follow an approach based on Abowd et al. [1], In that 
work, the authors apply the general approach of denotational semantics to software architectures with the 
fundamental insight that each architectural style needs its own semantic model. On this basis, Allen [2] 
provides an architecture description language based on CSP [13] to allow the specification and analysis 
of architectural styles. A different, though related approach is provided by Moriconi et al. in [18]. There, 
the authors use first order logical theories to describe architectural styles and they suggest to use the 
concept of faithful interpretation mappings to relate different styles. In a third approach, Le Metayer 
in [16] proposes to describe architectures as graphs and architectural styles as graph grammars with the 
aid of analyzing architecture evolution. Finally, Bernardo et al. [5] propose the use of process algebras 
to formalize architectural types, which arc weaker forms of architectural styles. 
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To build our model for layered architectures, we heavily rely on the intuition provided by informal 
descriptions of the layered architecture style. Some of the first documented descriptions of the style 
can be found in the work of Shaw and Garlan [20], where they identify a set of well-known styles 
observed in industry. Taylor et al. [22] elaborate on that work and distinguish between two kinds of 
layered architectures: the virtual machines style and the client-server style. Finally, there exists much 
literature from practicing architects documenting architectural styles and patterns. We consider [9] as 
one well-known representative of this kind of works. 

While all such references provide the necessary background for our study, there is another line of 
research on existing formal analyzes of architectural styles which is closely related to our work. In [12], 
Garlan and Notkin provide a formal basis for the implicit-invocation architectural style. The signal¬ 
processing style is analyzed by Garlan and Norman in [11]. Moreover, we can find a formal description 
of the pipes-and-filters style in the work of Allen and Garlan [3] and in Broy’s Focus-theory [8]. The 
Enterprise Java Beans architectural style is formally analyzed by Sousa and Garlan in [21]. In [18], the 
data-flow style is related to the pipes-and-filters style, the batch-sequential style, and the shared-memory 
style. The client-server style is described by Le Metayer in [16]. Finally, there are some formal analyzes 
of the layered architecture style. In [23], Zave and Rexford build a formal model of layered architectures 
and use the Alloy Analyzer [14] to analyze the style. Since their analysis concentrates on network- 
specific properties, it is a refinement of our model, thus, complementing our work. The work which is 
probably closest to our work is the one of Broy which provides a better understanding of the layered 
architecture style in [6]. 

In [6], Broy provides a model of services and of layered architectures based on the Focus theory [8]. 
In that model, a layer is a component with an import and an export interface and a layered architecture is 
a stack of several layers. Although that model is an important contribution towards a better understanding 
of layered architectures, the model represents computations explicitly using streams. Our model abstracts 
further away from such details of computations, concentrating on the major characteristics of the style, 
thus making the results applicable to several, different representations of computations. In fact, our 
model is based on an abstract notion of a service, and streams are just one possible realization thereof 
as shown in Ex. 3.2. Other realizations include stateless services as shown in Ex. 3.1 and more complex 
interactions as shown in Ex. 3.3. 

3 A Model for Layered Architectures 

In the following section we provide a model of layered architectures based on ports and services. With 
this model we want to provide the basis for a rigorous analysis of the style. Therefore, the model should 
be as abstract as possible and capture the intuitive understanding of the style to allow formulation of 
characteristic properties of the style. 

3.1 Ports and Services 

For our model of layered architectures, we assume the existence of sets PORT and SERVICE which contain 
all ports and services, respectively. Thereby, our notion of service is rather abstract; A service can be 
anything, from a simple method to a complex web-service consisting of a series of interactions. A port 
is a placeholder for a set of related services; one can think of the method’s signature or of the address 
of the web service. Thus, we assume the existence of a function type : PORT —y ^(SERVICE), (where 
p(X) is the power set of a set X) which assigns a type to each port. That is, the type of a port is simply a 
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*L 


*27 


bint mult(bint x, bint yj) { 
bint z := 0; \ 

*'-while (y>0) { \ 

z :=(add(x(zj)) 
y :=( sub(y,l); ) 

return z; 


(T 


*1 


*27 


static map<pair<bint,bint>,bint> cache; // lookup table 
(Sint mult(bint x, bint yj) { 

pair<bint,bint> p := make pair(x,y); 
if(cache.count(p)>0) // if lookup successful 
return cache[p]; 
else { //if the current input has not beencached yet 
bint z := 0; 

[hile (y>0) { 
z :=( add(x,z);) 
j^= (sub(y,l)0 

cache[p] := z; //store the result 

return z; 

} 


(a) Stateless (b) Stateful 

Figure 1: Stateful and stateless layers. The programming language type bint represents large integers. 


set of services. We require that each port is classified either as an input port or as an output port, but not 
as both. We let J’ be the set of input ports and G be the set of output ports: 

JUG = PORT and JffiG = 0. 

Ports and services constitute the parameters of our theory. By saying what port and services are, our 
theory can be applied to different contexts. 

In the following, let N + be the set of positive integers, Z the set of all integers. 

Example 3.1 (A model of stateless services). Consider the code depicted in Fig. la, where we write bint 
for bigint, a programming language type of large but fixed-size integers. In this example, we define the 
set of input ports as J* = {i \, L}, the set of output ports as G = {o}, where the ports are signatures, i.e., 
simplifying, strings: 

i\ = “bint add(bint,bint)”, io = “bint sub(bint,bint)”, o = “bint mult (bint, bint)”. 
Here, a service at a port will be a (set-theoretic) map whose signature is given by the port. For the sake 
of the example, let us fix some M e N + and use bint = [—2 M ,2 M — 1] for the set of representatives of 
integers modulo 2 M+1 , writing if for the representative of a G Z. The types of the ports arc sets containing 
certain partial or total maps from bintxbint to bint: 

• The type of i \ is the singleton set containing exactly the modular addition, which is defined for all 
arguments. 

• The type of L is the set containing partial and total maps s whose result coincides with that of 
modular subtraction whenever their first argument is positive and the second is 1. 

• The type of o is the set of total maps m that multiply the arguments x, y modulo 2 W ' 1 whenever y 
is nonnegative. Such m must return some result also for negative y. 

In this example, the types abstract away some details about termination and outcome and all details about 
the way the computations are performed. □ 
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The above example does not use any global state. In a more complex model, a layer may also 
have an encapsulated state, as it is the case for object-oriented programming languages. We can easily 
encode stateful models by changing the notion of service to relate streams of concrete values of the input 
parameters to streams of concrete return values, as we will see in Ex. 3.2. 

In the following, let No be the set of nonnegative integers and dom/ the domain of a (partial) map /. 

Example 3.2 (A model of stateful services). The code from Ex. 3.1 is slow. For the sake of the example, 
let us assume that some calls to mult arc often repeated with the same arguments so that caching would 
help reducing the running time, and let us cache every input-output pair in a simple way as in Fig. lb. In 
the worst case the cache grows until the memory is exhausted, after which we assume that cache insertion 
and all later events may block or have an arbitrary behavior. 

We assume that the cache operations arc purely internal and that the cache can hold at least N input- 
output pairs. We define the set of input ports as J? = {ii,h} and the set of output ports as fJ = {o\ 
again. Let sbint = (stream bint ) = bint* \Jbint m be the set of streams over bint, i.e., the set of finite and 
countably infinite sequences over bint, where we index the elements of a stream by the corresponding 
downward-closed subset of No- We lift the previous types of /) and h pointwise to streams as usual; e.g., 
type(i\) = {a £ ( sbint x sbint — > sbint ) | \/r,s,t £ sbint : a(r,s ) = t =>■ (dom? = (domr) n (dom j) A Vi £ 
dom /: t(i) = r(i)+s(i))}. We define type(o) to be the set of all maps m £ ( sbintxsbint —> sbint) such 
that whenever m(r.s) = t for streams r.s.t £ sbint and i £ (domr) n (dom s) is such that the number of 
cached entries | {(r(j),s(j)) £ bint 2 \ j<i A j £ (domr) n (dom.9)}| is below N, then i £ dom/ and we 
have (s(i) >0 t(i) = r(i)s(i)). 

Loosely speaking, types containing functions over streams have just helped specifying stateful ab¬ 
stractions of stateful services without actually referring to their state spaces. □ 

Example 3.3 (A model of complex services). In Ex. 3.2, a service is still realized by a simple method 
which depends on a global state. However, we could also think about models in which a service is 
actually realized by a series of method calls, coordinated by some kind of protocol. By adjusting the 
concrete notion of service, our theory can also be applied to those kind of models. Here, the behavior 
of the services relates streams of concrete values for all the input parameters of all the methods in the 
series with streams of output values of all the return values of the series. Ports arc then a set of method 
signatures equipped with an expected order of execution. Again, an output port specifies methods which 
can be called within the layers implementation while an input port specifies those methods realized by a 
layer. □ 


3.2 Valuations 

For a set of ports P C PORT, a valuation is a function from the set P to the set of services that respects the 
types of the ports. By P we denote the set of all valuations for P, formally, 

p = n l yP e( yP) ■ 

peP 

Sometimes, we shall use [po, ■ ■ ■, p n ^ So,... ,5„] to denote a valuation of ports po ,.... p„ with services 
So,-.-,S n , respectively. Formally, 


„] = Xp £ {pi | i £ Nq A i < n}. 


So if p = po, 


[Po, ■ ■ ■ ,Pn h ~> So, ■ ■ ■ ,S, 


S n if p = p n . 
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0 1 0 ~> 

- A-- O -=-- 

f € (l-> p(0)) with f(i) = {o<EO I 0 ( 01 ) =i(ii) A 0 ( 02 ) = 1 ( 12 )} 


12 


Figure 2: A layer with input-ports I, output-ports 0 and behavior function /. 


Example 3.4 (Valuations for services). In the models described in Ex. 3.1, 3.2, and 3.3, a port valuation 
just associates a services behavior with the corresponding method signature. □ 

3.3 Layers 

Informally speaking, a layer consists of input ports, output ports, and some behavior that generates 
services at output ports from services at input ports. The behavior may be nondeterministic, so we 
represent it by a map that assigns a set of output-port valuations to every input-port valuation. 

Definition 3.5. A layer is a triple (7, O.f), where 7C/, OC0, and/: l^p(0). 

For a layer / = (7, 0,f), we denote by l.in its input-ports 7, by l.out its output-ports O, and by l fun 
its behavior function /. We denote the set of all layers by «2f. 

Example 3.6 (A simple layer). Consider, for example, the layer depicted in Fig. 2, which just copies 
ij to Oj for j E {1,2}. In our model, such a layer is represented as a triple (7,(9,/) with input-ports 
7 = {hth}, output-ports (9 = { 01 , 02 } and behavior function / e (7 —> p(0)) with f(i) = {o e (9 | 
0 ( 01 ) = i(ii) A 0 ( 02 ) = 1 ( 12 )}. □ 

3.4 Layered Architecture Configuration 

A layered architecture configuration consists of a set of layers and an attachment describing the con¬ 
nections between the layers. Thus, a layered architecture configuration is modeled as a pair of a set of 
layers and a so-called attachment relation describing which output ports of which layers convey services 
to which input ports of which layers. 

In the following, we denote by 

X—+Y = {fQXxY\Vx,y 1 ,y 2 :((x,yi)efA(x,y 2 )ef)=>yi=y 2 } 

the set of partial maps from a set A to a set Y. 

Definition 3.7. A layered architecture configuration is apair (L, A), where LCif” andAe ( (\J 1 - 1 J ■in) --■» 
(U/gl Lout)), called the attachment, are such that the following constraints hold. 

• Different layers do not share any ports, formally: 

Vk,/EL: k = / V (k. in Uk. out) (1(1. in U/. out) = 0. 

• If a service is provided at an output port that is connected to an input port, the layer owning the 
input port must be able to employ the service, i.e. the port types arc compatible. Formally: 


V (pi,p 0 ) € A: type(p 0 ) C type (pi). 
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Definition 3.10. Given a layered architecture configuration c and a port p £ Lin U Lout for some l £ c.l, 
we define the layer projection 

o p (c) = l. 

By Def. 3.7, the layer possessing a given port is unique, so a (.) is well-defined. 

3.5 Semantics 

Now we are going to define the computational meaning of a layered architecture configuration. 

In the following, for a map /: X—»F, we write f\z for the restriction of / to the domain XDZ. 

Definition 3.11. For a layered architecture configuration c, the attachment-closure Lout* of the output 


ports of a layer 1 is 

Lout* = f]{PCYl (c)\ Lout CP (1) 

A (V (/, o) £ c.conf: i £ P o £ P) (2) 

A (Vo £ n„ (c) : o £ P =>- o a (c) .in CP)}. (3) 


The configuration semantics of a layer / £ c.l is a function |7] c : IT,-,, (c) -» p [Lout) , with 

Mc(a 0 = {v|/. 0M f I V £ Lout* (4) 

A ll\i.out* = v |n,-„(c) (5) 

A (V/ £ n,- (c) n l.out* : (v(z) = V (c.conf («)))) (6) 

A (Vo £ n„ (c) fl Lout* : 

^ *5 F O 0 (c) .Jun(v | a 0 (c).in) • 'al/.ouf* V | cs 0 (c).out) } (7) 


In (4), we would not like to use all the II (c) instead of l.out*, since, informally speaking, there might 
be no consistent valuation of all the ports, but there may be a consistent valuation of a subset of ports 
that is sufficient to define the output of the layer. Instead we use the minimal set of ports including Lout 
and closed under the attachment relation. 

Each element of the semantics |[/] c (ju) is created by constructing a valuation v of the ports Lout* of 
the configuration that arc needed for getting the value of the output ports of / and projecting v to these 
output ports. In fact, line (4) says that v provides a valuation of all needed ports. Line (5) says that the 
valuation of an open input-port must be taken into account if and only if we need this port. Line (6) 
says that if we require the value of a connected input-port, then we use the value of the corresponding 
output-port. Line (7) says that if we need a service provided by a layer, then the computation proceeds 
according to the layer’s behavior function. 

Example 3.12 (Calculating a layer’s configuration semantics). Consider, for example, the layered archi¬ 
tecture configuration c = ({ lf,l g },A ) in Lig. 4a. 

Here, l f = ({*o,io}>{°o,Oo},/) and l g = ({q,ij},{oi,oj},g) with {*o,*o>*t>*'i} £ J, {o 0 ,<4oi,oj} C 
G, and A = {(/(,,oj),(/j,o(,)}. 

Lor the sake of this example, let’s assume that {B,C,D,F,X,Y} C SERVICE and type(io) = {#}, 
type (i' 0 ) = type (oj) = {X, F}, type (;)) = {D}, type (/j) = type (o' 0 ) = {X, F}, and type (o 0 ) = type (oi) = 
{C.F}. Here, we use symbols B.C.D.F for services at externally visible ports (z'o,oo, h,o\) and X. F for 
services at internal ports (i' () .o' () .i\ .o\). 
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o i 
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o o 

io 

(a) Before update. (b) After update. 

Figure 4: Layered architecture configuration consisting of two layers If and l g . 

The behavior functions are as follows: 

f : {i - 0 )*o} ^ p({°o>Oo}^ , [kid'o ^ B,X] ha {[oo,Oq ^ C,X]}, 

[;'o,;'q t—?B,Y] ha {[oo,o' 0 h > T,X]}; 

8’- {h,i[} p({oi,o' 1 }') , [h,i[^D,X] ha {[ 01,01 ha C,X]}, 

[/!,/{ haD,F] ha {[01,o'j ha F,y]}. 

Let us now apply Def. 3.11 to calculate [Z/] c (m) ^ {°o,Oo} and [/g] c (M) C {o 1 , 0 ^} for p = [;'o, ;'i ha fi,D], 
Therefore, we first calculate all elements v e IT (c). For our simple system, v satisfies 

v (io) = /i(io) =5, v(m) =/i(ii) =D, 

v (i' 0 ) = v(o' l )=X, v (/•;) = v (o') = X, 
v (o 0 ) = C, v(oi) = C. 

Note that v is the only element of IT (c) that satisfies the constraints that should hold for each element of 
[•]c(m) according to Def. 3.11. Thus, 

Vfic(v) = {v|{ O0)O '}} = {[ 00 ,Oq ha C,X]} and 
llgUE) ={v| {0l)0 ' l} } = {h, 0 WC,X]}. 

□ 

3.6 Semantic Change 

A key concept in developing a piece of software is changing the semantics of a layer. We model such a 
change of the semantics of a layer through an update function. 

Definition 3.13. For a layer / and a map f: l.in -A p(l.out), a semantic update [/ ha/] is the layer 
(, l.in, I.out, f ). 

Note that a semantic update is indeed a layer according to Def. 3.5. 

The notion of semantic update easily generalizes to sets of layers L C j£f: 

L[/ha/] = (L\/)U{[/ha/]}. (D 3) 

Finally, it also generalizes to layered architecture configurations: 




c[l^ f] = ( c.l [1 ha /], c.conf). 


(D 4) 
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Example 3.14 (A semantic update for a layered architecture configuration). Consider, for example, the 
layered architecture configuration c = (L,A) depicted in Fig. 4a and described in Ex. 3.12. 

If we change the behavior of layer If to 

f'- {iod’o} a*■ , [*o j*’ o ^rA {[oo,Oq ha C,X]}, 

M 'A S,F] a {[°o,o'o A 

we get a new layered architecture configuration c [If i-a f] where layer If has changed to (If. Of ,f) (see 
Fig 4b). Applying Def. 3.11 to calculate C {oo,Oq} and C { 01 , 0 ;} for 

ji = [r'o, /1 a- B.D. produces, in addition to v, a new valuation v', which satisfies 

v'(f 0 ) = /i(i 0 ) =B, v'(ii) = n(h) =D, 

v 7 (i'o) = v' (o\) = Y, v'(i') = v'( 0 ') = F, 

v'(o 0 )=F, v' (oi) = F. 

Note that V satisfies the constraints that should hold for each element of (jtt) according to Def. 

3.11 and that v, v 1 arc now the only elements of II (c) which do so. Thus, 

Vfi c (m) = {vI {ooi0 / } , v'I {o0i0 / } } = {[o 0 ,o'o ^ C,X], [00,Oo ^ E,F]} and 
iy c [i f ^f](^) = { v l{o,,o' 1 }’ v/ |{o 1 , 0 ',}} = {[o\,o\ 1 -+C,X],[oi,o\ aE,F]}. 

□ 

In the above example as well as in general, a semantic update of a layered architecture configu¬ 
ration changes neither the input/output-ports nor the attachment, thus producing a layered architecture 
configuration again: 

Proposition 3.15. For a layered architecture configuration c, layer l G c.l, and a map f: l.in -a p ( Lout ), 
the layered architecture configuration update c [/ 1 —> f] is a layered architecture configuration. 

Thus, all properties and notation introduced so far for layered architecture configurations are also 
valid for layered architecture configuration updates. 

3.7 Syntactic Dependency 

In a layered architecture configuration, the attachment relation induces a dependency relation between 
layers. We say that a layer l' syntactically depends on another layer /, if an input port of l' is connected 
to an output port of /. 

Definition 3.16. Syntactic dependency for a layered architecture configuration c is a relation A c C 
c.l x c.l defined by 

/ Ac l' 4A 3 o G Lout , i G l'.in : o = c.conf (i). 

Example 3.17 (Syntactic dependency). In the layered architecture configuration depicted in Fig. 3, we 
have lj A c li + 1 for i G {0,... ,n— 1} and no other syntactic dependencies. □ 

For a layered architecture configuration c, we denote by A+ the transitive closure of A c and by A* 
the reflexive-transitive closure of Moreover, we denote by A c _ : c.l —> p(c.l), defined via 

A c m = {l G c.l | / Ac m} for m G c.l , (D 5) 

all layers / that a given layer m syntactically depends on (A ( + _, A* _ for [reflexive-] transitive depen¬ 
dency, respectively). 
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Lemma 3.18. For a layered architecture configuration c, and layer l £ c.l, the attachment closure l.out* 
contains only ports of layers on which layer l reflexively-transitively syntactically depends on. Formally, 
Vp £ l.out *: Op (c) -<* 1. 

Proof. Let /: p(Yl (c)) -A p(Jl (c)), 

P H > l.outU{o | 3i€P: (, i,o ) £ c.conf} U (J {r.in \ r £ c.l A PFront f 0}. 

Using the fixed point theorem of Tarski one can show that l.out* = U«eN 0 /”(®)- a layered archi¬ 
tecture configuration c and one of its layers / £ c.l. We show that Vn £ No Vp £ /"(0) : o p (c) -<* l by 
induction on /. 

“Vp £ /°(0): o p (c) -<* Since /°(0) = 0, the statement is vacuously true. 

“Vp £ /''(0): (Tp (c) -<* / implies Vp £ /' !+1 (0): o p (c) -<* Fix p £ /' ,+1 (0). At least of the following 
cases is true. 

Case p £ /.ont: By Def. 3.10, (c) = / and by reflexivity, / -<* 1. Thus, <7 P (c) -<* l. 

Case p £ {o \ 3i £ /”(0): (;,o) £ c.conf }: Then there is an / £ /"(0) such that (i,p) £ c.conf. 

By Def. 3.10 and 3.7 we have i £ a* (c) .in and p £ o p (c) .out. From (i,p) £ c.conf we obtain 
Op (c) A c ct# (c) by Def. 3.16. Since i £ /"(0), we have o, (c) -<* l by induction hypothesis. By 
transitivity, o p (c) -<* 1. 

Case p £ IJ {r.in | r £ c.1 A/”(0) Fr.out f 0}: Then there is an r £ c.l such that /"(0) Front f 0 
and p £ r.in. Since /"(0) Cl r.onf / 0, we have r A* l by induction hypothesis. Since p £ r.in, we 

have o p (c) = r by Def. 3.10. Thus, we conclude Op (c) A* /. □ 

Note that the syntactic dependency relation is not transitive in general: just because a layer L\ depends on 
another layer Li which depends on a third layer L 3 , this does not necessarily mean that layer L\ depends 
on layer L 3 . 

3.8 Semantic Dependency 

Besides the syntactic dependency relation between layers of a layered architecture configuration we also 
have a semantic dependency relation between those layers. A layer V semantically depends on a layer / 
if updating / may influence the configuration semantics of 1'. 

Definition 3.19. Semantic dependency for a layered architecture configuration c is a relation <C c C 
c.l x c.l defined by 

/ <C c / 3f £ (Tm -> p(l.out)) : [Z] c 7 ^ [[/ *->• f]} c [b-+f] for all / in c.l and 
l <C c l' 3f £ (Lin -A p(l.out)) : [[/']] c / PIcI/h-/] f° r all in c.l. 

Now we provide simple examples of semantic dependency and independence. 

/ 

I_ 


;_ qj 




Figure 5: A simple layered architecture configuration with 2 layers. 
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Example 3.20 (Semantic dependency). As an example, consider the simple layered architecture config¬ 
uration depicted in Fig. 5 where changing the behavior of layer 1 does indeed influence the configuration 
semantics of layer V. 

In order to see this, we first need to formally define the behavior functions / £ (7 —> p (O )) and f e 
(/' —> p(O')). Let us assume that {A,B,C,D,E,F,X,Yj C SERVICE and type(io ) = {A}, type(oo ) = 
{B}, type{o\) = type(i\) = {A}, type(o 2 ) = type(i 2 ) = {F,Z}, type(i ' 0 ) = {C}, type(o' 0 ) = {D}, type(o \) = 
{£"}, and type(o ' 2 ) = {F.G). Here, we use symbols ,4. B. C. D.E.F for services occurring at externally 
visible ports (io,oo ,and A. Y for services occurring at internal ports (o\ , 02 ,i\ ,i 2 ). 

Let / : {; 0 } -> p ({ 00 , 01 , 02 }) and f : {i' 0 ,i' v i 2 } p(io' 0 ,o[,o' 2 }) be defined by 

/([* 0 ->A]) = {[o 0 ,o u o 2 f+B,X,Y]}, 
f ( \i'oA,i' 2 ^C,X,Y\) ={[o' 0 ,o[,o’ 2 ^D,E,F}} i 
fiKA ,*2 ^ C,X,Z}) = {W 0 ,o[,o' 2 i y D,E, G]} . 

Now we calculate [/] c : {io,i' 0 } -A P ({ 00 , 01 , 02 }) and [[/'] c : {*o,*o} p(i°b’°'v A}) b y Def - 311: 

ll} c ([ioAo^AC]) ={[ 00 , 01,02 ^B, A, Y}}, 
ll'M[hAo*A,C\) = {[o' 0 ,o' 1 ,o' 2 ^D,E,F}}. 

If we now replace / by g : {/o} —> p ({ 00 , 01 , 02 }), defined as 

g([4) 1 —> A]) = {[o 0 ,Oi,o 2 H-S,A,Z]}, 

we can see that / because calculating [/] C [ /H , g ] : {/o,/q} —> p ({ 00 , 01 , 02 }) and : {?o, i' 0 } —>■ 

P ({oq, 0 }, o{}) by Def. 3.11 results in 

Wc[/H-g] ([io/o 1 —A,C]) = {[ 00 , 01,02 5,A,Z]}, 

ll%li^]([ioAo^A,C}) ={[o',o;,o' ^D,E,G}}. 

and we see that / [/']. □ 

Example 3.21 (Semantic independence). In the simple layered architecture configuration in Fig. 5 
changing the behavior of layer / does not influence the configuration semantics of layer /. 

Let us assume behavior functions / : 7 -» p[0 ) and f \ V —y p{0 ') of Ex. 3.20. Then we can see 
that there is no behavior function g:V —y p ( O ') such that [[//.[/= ^ / [[/]. This is the case, because the 
semantics of l does not depend on any inputs from V. Thus, we have l' Ac l■ □ 

3.9 Relating Syntactic and Semantic Dependencies 

Having a formal model of layered architecture configurations allows us to analyze the relationship be¬ 
tween syntactic and semantic dependencies. 

An interesting property is that if layers arc syntactically dependent, this does not necessarily mean 
that they arc also semantically dependent. 

Example 3.22 (Syntactic dependency does not necessarily imply semantic dependency). Consider a 
single layer with just one input and just one output port that are typed by the empty set of services and 
attached to each other. According to Def. 3.16, the layer depends on itself syntactically. However, it 
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is not possible to change the layers configuration semantics at all, since the layer’s behavior function 
is the only map from the (empty) set of valuations of the input port to the (empty) set of valuations 
of the output port. Thus, according to Def. 3.19, the layer does not depend on itself semantically. In 
general, if SERVICE = 0, any configuration with a nonempty attachment will have a pair of layers with 
this property. □ 

However, under certain circumstances, syntactic dependency does indeed imply semantic depen¬ 
dency. 

Definition 3.23. A layered architecture configuration c is usable iff there is at least one valuation of open 
input-ports such that the configuration semantics of every layer produces at least one output valuation on 
this input. Formally: 

Hpf - 

c usable 3p € n„, (c) V/£ c.l: |7] c (jU) 7 ^ ®- 

Theorem 3.24. For a usable layered architecture configuration c the reflexive-transitive closure of syn¬ 
tactic dependency implies semantic dependency. Formally: c usable => A*C<C c . 

Proof Let c be usable and / -<* V. So there is some p £ n,„ (c) such that |[/ , ] c (ju) f 0. Let g : l.in —> 
pil.out ), / 1 —> 0. If / = l', then [[/' >-)• g]] c [/v-»-g](M) = 0. If / f l', we inductively follow that all the layers 
r f 1 such that 1.out n r.out* f 0 satisfy [[r] c [/^^] ip) = 0. In particular, [/ , ] c [/i—s-g] (m) = □ 

Vice versa, if layers are semantically dependent, they are not necessarily (directly) syntactically 
dependent. 

Example 3.25 (Semantic dependency does not necessarily imply syntactic dependency). Consider a sin¬ 
gle layer with one output port that is typed by two services and no other ports. According to Def. 3.19, 
it depends on itself semantically. However, according to Def. 3.16, it does not depend on itself syntacti¬ 
cally. Indeed, it does not have any syntactic dependency at all. 

A less trivial example is demonstrated in Fig. 6 , where SERVICE = {A.B). all ports are typed by 
SERVICE, l fun = Av£0.{[o i —> A]}, l' fun = Av £ {/ / }.{[o / i-A v(i')]}, and l" fun = Av £ {/ // }.{[o" H > 
v(/")]}. We have / < c but / / c l". □ 


i = (0,{»},/) = WFwuflf- 


Figure 6: A thrcc-laycrcd configuration with c.l = and c.conf as shown. 


As we see, changing the behavior of a single layer may impact not only the configuration semantics of 
directly depending layers, but also of layers which transitively depend on the modified layer. 

This property of layered architecture configurations implies that a test after a change of a layers 
behavior should include tests of the behavior of all semantically dependent layers. As we will see in a 
moment, there is a bound on how many layers one should test. 

Theorem 3.26. Semantic dependency implies the reflexive-transitive closure of syntactic dependency. 
Formally: <C c C-<*. 

Proof. Fix a layered architecture configuration c, its layers /,/' £ c.l such that / f*. /'; we will show 

/</'. _ _ _ 

Notice that / f l'. Fix arbitrary /: l.in —> p [l.out) and p £ n,„ (c). We are going to show that [[/'^(jU) = 
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“C”: Let K £ [[/'] c (/i). By (4) of Def. 3.11 there is some v e Lout* such that v|//. 0Mt = K and (5), 
(6), (7) hold for K and l'. Since l' does not reflexively-transitively syntactically depend on 1, by 
Lemma 3.18 no ports of l arc in l'.out* and we readily conclude that (4), (5), (6), (7) still hold for 
K and l' if c is replaced by c [l ^ /]• Thus k £ I^]c[/i-r/](M)- 
“D”: Analogously. □ 

Informally speaking, this property allows us now to restrict testing after a modification to only those 
layers which (reflexively-)transitively depend on the modified layer. 

Corollary 3.27. For usable layered architecture configurations, the semantic dependency and the reflexive- 
transitive closure of the syntactic dependency are the same. 

4 Conclusion 

With this work we provided an abstract model for the layered architecture style. Our model is based on 
the notion of services and ports which can supply services. A layer consists of input and output ports 
and is modeled as a function from input-port valuations to output-port valuations. A layered architecture 
configuration consists then of some layer instances and an attachment describing the connections between 
layers’ input and output ports. 

We have given a formal definition of syntactic and semantic dependency between layers. Though 
syntactic and semantic dependencies do not necessarily imply one another, we have shown that the 
semantic dependency implies the reflexive-transitive closure of the syntactic dependency, and the reverse 
also holds for usable configurations. 

Having developed a formal model of layered architectures, the model can now be used for a rigorous 
analysis of the style. Thus, future work arises in two main areas: (i) First of all, different valiants of the 
style should be identified and defined through constraints over our model. For example, a “basic” valiant 
of the style would impose a well-foundedness constraint on the attachment relation and a “strict” valiant 
would further constrain the attachment relation to be antitransitive, (ii) Then, for each valiant, a set of 
properties should be formulated and proved from the constraints. For example, in the “basic” valiant, we 
may want to provide conditions that ensure that the configuration is usable. Moreover, the configuration 
semantics of lower level layers may be strictly independent of the behavior of upper level layers and 
under certain circumstances, the configuration semantics of upper level layers may also be independent 
of the behavior of lower level layers. In the “strict” version, changing a layers behavior may have even 
less impact on the configuration semantics of other layers within the architecture configuration. 

Our work aims to contribute to a rigorous theory of architectural styles to provide a better under¬ 
standing of architectural styles and the formal relationships between architectural design decisions and 
quality attributes. Thus, two further directions for future work arise: (i) The approach used in this article 
should be applied to other architectural styles as well, (ii) Then, a general theory of architectural styles 
should be developed to investigate relationships between the different styles. 
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